User-Centred Requirements Handbook |
The aim of this section is:
• To review current processes for achieving user goals and to document problems that may arise within that process.
• Highlight possible ideas for addressing the problems that may arise.
Process
For each goal (e.g. G1, G2 etc.) complete Form 1.8, listing the basic steps in achieving that goal. Task steps might be identified by means of group discussions (see section 4.6) or interviews (see section 4.7). It may also be necessary to observe tasks (section 4.8) currently being performed to identify the individual steps.
To complete the form, carry out the following steps:
1. Break the goal down into a series of task steps.
2. Review each task step, and think about possible problems, events or task variations that might affect the basic flow of the task. Write down any such problems or unusual events in the second column. These form the basis of scenarios that will be used to test the feasibility of the system design.
To generate such problems consider, for example any inputs or task dependencies. For a bank machine, they would be the bank card and knowledge of the PIN. This could lead to the problem of the user forgetting the PIN after inserting the card. Similarly another aspect is the danger of theft, so the problem to be noted of the user being robbed, or feeling suspicious about the person standing behind them in the queue. Not all items need be problems — they may be opportunities for design ideas. Thus a characteristic of bank machine usage is that the user withdraws the same amount of money on 90% of occasions, for which a quick interaction path could be designed.
3. Now consider possible user requirements that could overcome the problems or variations listed. Write these in column 3. These are then taken forward into the development of the new design concept within Phase 2.
For tasks that need to be analysed in more detail, a Task Analysis should be carried out. (see section 4.15 in Part C, for further description). This includes diagramming techniques Task Flow Diagrams and Task Decomposition.
Refer also to RESPECT D4.2, section 3.3.2, on task related factors
which will help to identify user requirements based-upon particular
types of task, either: data entry, querying a database, reading or
browsing, lengthy and complex tasks, monitoring and safety critical
tasks, and task interruptions.
Form 1.8 - Current Process (Example)
| 1.8 Current Process | |||
| User group or groups concerned: Bank customer | |||
| Goal: G1 Access required service quickly and safely (e.g. Withdraw cash) | |||
| Form completed for all user goals listed in Form 1.7 | |||
| Task Step | Problem/Task variation | Potential User requirement | Ref. |
| 1. Line up to use bank machine. | |||
| 2. Insert card. | Card inserted wrong way around. |
Notch on card. Picture on machine as guidance |
1.8.1 1.8.2 |
| 3. Enter PIN. |
User forgets PIN. Machine abandoned. Machine breaks down. Next person in queue takes too much interest in transaction. |
Allow thumbprint. Quick reset button. Provide more privacy with surround on machine |
1.8.3 1.8.4 1.8.5 |
| 4. Select 'withdraw cash' service. | |||
| 5. Select or enter required amount. |
Amount required greater than current limit. Machine runs out of money. User decides not to proceed with transaction. User selects same amount of money on most occasions. |
Display amount available. Provide cancel button. Provide short cuts to commonly required options. |
1.8.6 1.8.7 1.8.8 |
| 6. Choose whether a receipt is required. | Machine runs out of paper. | ||
| 7. Take card. | Card not returned. | ||
| 8. Take money and receipt (if chosen). |
No money and/or no receipt returned. Incorrect amount of money returned. User threatened by passer-by and money stolen. |
Provide button to register problem at given time. (See above) Camera on machine to video transactions |
1.8.9 1.8.10 |
All information used to generate Transfer to relevant forms
task scenarios and propose new especially 3.5 Functions/Features
processes in Section 2.4